XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/540")

_{Built from 4a07b75}

@claude review this PR.

Claude finished @iangmaia's task in 0s —— View job

I'll analyze this and get back to you.

Claude finished @iangmaia's task in 0s —— View job

I'll analyze this and get back to you.

FYI #533 isn't merged so ofc this won't trigger the new Claude workflow.

@claude review this PR, now that #533 landed and the workflow is secured.

Claude finished @mokagio's task in 0s —— View job

I'll analyze this and get back to you.

@iangmaia looks like the Claude review run but never went past reporting that it started? I had a quick look at the logs, https://github.com/wordpress-mobile/GutenbergKit/actions/runs/28994702797/job/86041799638, but couldn't make much of it. Haven't passed it to my AI for further investigation, but can do that later if you don't have the bandwidth.

@iangmaia looks like the Claude review run but never went past reporting that it started? I had a quick look at the logs, https://github.com/wordpress-mobile/GutenbergKit/actions/runs/28994702797/job/86041799638, but couldn't make much of it. Haven't passed it to my AI for further investigation, but can do that later if you don't have the bandwidth.

It seems to be a problem with the token, which doesn't surface properly. See anthropics/claude-code-action#1249.
I'll create a new token and update it in the action secrets.

@claude review this PR.

Claude finished @iangmaia's task in 1m 16s —— View job

PR Review: fix(e2e): stop wp-env warm-up JSON parse flakes

• Read changed files (.wp-env.json, bin/wp-env-setup.sh, e2e/wp-env-fixtures.js)
• Analyze diff vs origin/trunk
• Provide review feedback

Overall this is a solid, well-reasoned fix. The root-cause diagnosis (PHP notices / transient 5xx corrupting the first REST body, poisoning module-scoped caching only-on-success) is convincing, and the three layers address it at the right places. The code is clean, the JSDoc is genuinely helpful, and the error messages now surface a body snippet instead of the opaque Unexpected token '<'. Nice work. A few thoughts below — none are blockers.

🟡 fetchJson retries every error, not just transient ones

e2e/wp-env-fixtures.js:78-83 — the catch treats all failures identically, so a genuinely permanent error (e.g. 401/403 from a bad authHeader, or 404 from a wrong route) is retried the full 15× 2s = 30 s before failing. The JSDoc and PR description both say "retry transient 5xx/parse failures," so the code is slightly broader than advertised.

This isn't wrong for CI resilience, but failing fast on non-retryable status codes would make a real misconfiguration surface in seconds instead of after a 30 s hang, and would match the stated intent:

if ( ! response.ok ) {
    const message = `HTTP ${ response.status } ${ response.statusText } — ${ body.slice( 0, 200 ) }`;
    // 4xx (except 408/429) won't fix themselves on retry — fail fast.
    if ( response.status < 500 && response.status !== 408 && response.status !== 429 ) {
        throw new Error( `Failed to fetch ${ label }: ${ message }` );
    }
    throw new Error( message );
}

(A network-level fetch() rejection and a JSON parse failure should still retry, since those are the transient warm-up cases.) Fix this →

🟢 Redundant readiness gating (by design, worth a note)

bin/wp-env-setup.sh:183-208 gates on the settings endpoint returning valid JSON, and fetchJson then retries the same endpoint again. That's intentional belt-and-suspenders and I think it's justified for a flaky suite — but note the setup gate only covers wp-block-editor/v1/settings, not the wpcom/v2/editor-assets endpoint, so the in-test retry still carries real weight for assets. No change needed; just flagging that the two layers aren't fully redundant.

🟢 Minor: duplicated inline Node JSON-parse snippet

bin/wp-env-setup.sh now embeds the same process.stdin … JSON.parse node snippet twice (app-password extraction at ~L128 and the readiness gate at ~L190). Not worth a helper for two occurrences, but if a third appears it'd be worth extracting.

🟢 Nits

• e2e/wp-env-fixtures.js:87 — lastError.message is safe here since MAX_FETCH_ATTEMPTS is 15 (the loop always runs at least once and assigns lastError before this line). Fine as-is; just noting the invariant isn't obvious.
• The 200-char body snippet in error messages could echo part of the editor-settings payload into CI logs. For local/CI test infra against localhost this is a non-issue, but worth keeping in mind if these fixtures are ever pointed at a shared instance.

Testing & standards

• .wp-env.json — WP_DEBUG_DISPLAY: false while keeping WP_DEBUG_LOG: true is exactly the right call: notices stay in debug.log but never leak into REST bodies. 👍
• The polling-in-tests tradeoff the author raised is reasonable for E2E warm-up; bounded retries with a hard cap and a diagnostic final error is the acceptable form of it.

Great targeted fix — my only real suggestion is the fast-fail-on-4xx tweak; everything else is optional polish.